To date, computer-based word processing systems have been dedicated primarily to text processing and have had limited, if any, data processing capabilities. These word processing systems have been marketed as complete systems typically including a keyboard, display, processing unit, magnetic media storage device, document printer, and software. Since these systems were dedicated machines sold as a total package of hardware and software, the printer access method (i.e., the set of programs for translating a text data stream into a printable data stream) could be relatively simple and did not need to have the flexibility necessary to allow the processing unit to print documents on printers other than the printer with which the processing unit was initially sold.
The modern trend in consumer preference has been away from the dedicated word processing systems and toward the small, general purpose business computers capable of both text and data processing. Since data processing places few special requirements on a printer, many diverse printers have become available. In addition, purchasers of these small business computers often purchase the processing unit from one source and the printer from another source. While mixing product sources may cause no problems in the field of data processing, the source mismatch may cause problems when complex text processing is attempted. For example, complex text processing may require different line pitch (e.g., 5.3, 6, 8, or 24 lines per inch), different line spacing (e.g., 0.5, 1, 1.5, 2, or 3 lines), different character pitch (e.g., 8.55, 10, 12 characters per inch, or proportional spacing), and advanced text functions (e.g., superscript, subscript, underscore, or boldface), and these functions may be required at different times during the printing of a single text document.
To complicate the problem, there is little, if any, standardization of printer commands for these complex text functions. Even printers that claim to be replacement or equivalent printers are often different when performing the more subtle of these complex functions.
One known solution to this problem of processing unit/printer mismatch has been to provide customized print formatting routines for each printer that is to be supported. For example, the IBM text processing program Displaywrite 2 has support for four printers (IBM graphics printer, IBM matrix printer, IBM 5218 printer, and NEC 3550 printer). With this customized printer support, the text program sends the correct print commands to the destination printer to perform the intended function. This solution has two principal failures. First, only a limited number of printers can be supported, and second, even though some printers claim to be replacement or equivalent printers, printer function of so-called equivalent printers often varies in response to the same print command.
Another known solution is to provide a simple translation table that is changeable by the system user. This solution transforms a text data stream into a printable data stream by looking in a table for individual print commands corresponding to individual text commands in the text data stream. The individual print command entries in the table are changeable by the user to allow different print commands to be produced for a given text command depending on the printer supported. This solution has several limitations including requiring a fixed amount of storage for the translation table regardless of the complexity of the supported printer. With this fixed length table, a given text command always addresses the same entry in the table. In order for the table to support complex function printers, the table must be large (e.g., 2k bytes of memory). If a printer does not support the function indicated by the print command represented by the addressed entry, the entry is set to zero but continues to occupy a position in storage. This fixed length table is overkill for some simple function printers, thereby wasting valuable storage space, but for more complex printers, the fixed table may prove inadequate. In addition, the simple table approach requires a separate table entry for each anticipated printer function. For example, in order to support five different print pitches, the table would require five separate table entries. This replication also represents wasted storage space.